iT邦幫忙

DAY 13
9

高有效性 (High Availability) 初論 30 講系列 第 13

高有效性簡介30篇: 高效能與效能調校 (13)

  • 分享至 

  • xImage
  •  

**高有效性 High Availbility 而言並不是可以運作就好, 而是這個運作是可被使用者接受, 或者是符合 BI 企業智慧, 甚至是最大的重點是符合 User Expierence (使用者經驗) 的優化 Optimization, 也就是 UEO, 這其中最重要的就是效率要能夠對應使用者的期待, 算出來的結果也要讓使用者接受, 而這個條件就是要效率與效能達到一定的標準.

當然效能調校的第一步驟就是我在這專題寫的第一項: Monitor and Alert, 也就是說把效能做一定的監控, 才有可能做效能調校的下一步, 而往往效能的瓶頸是會導致失效的最主要原因之一, 而若能把效能的瓶頸提升, 這部份的 Failuare 才有可能進一步的避免.**
要追求效能一定要知道瓶頸在那邊?

  1. 使用者終端
  2. 使用者網路端
  3. 網路骨幹端
  4. 網站上流端
  5. 網路設備端
  6. 伺服器端
  7. 資料庫端
  8. 程式端
  9. 作業系統端
  10. 系統架構端

當然這每一個項目都還有很多細項, 像一台機器往往也會有記億體, CPU, 匯流排, 儲存設備, I/O 等等的瓶頸, 無論是在量的瓶頸或效率的瓶頸, 要把每一項瓶頸去做確認, 並找出原因, 這就是效能調校最大的工夫.

事實上效能說是高有效性的一環, 相對的, 高有效性也是高效能的手段之一, 因為現在的效能已經也不是只靠一台機器, 而是靠許多台機器去完成, 在某方面就必須包含一個具有 Fault Tolerance 的一個系統.

只是機器越多, 要讓所有機器一起運作做同一件事, 一定會有多餘的負荷 Over Head, 如何降低這個多餘的負擔, 至少不會產生 Threshold 讓要去共同運作所須要的資源反而超過加入一台機器能給的資源, 這反而又形成另一個瓶頸.

能夠提升效率的源頭就內部的資源控制有很多方法:

  1. 演算法
  2. 程式語言
  3. 程式設計方式
  4. Framework
  5. 作業系統
  6. 機器效能
  7. 資料庫
  8. 流程架構

每一個細項都有可能造成很大的影響, 尤其我們最不想承認的一些系統本身就有天生的優缺點, 甚至有些是很意識型態的紛爭, 但說起來還是資源與公司政策與政治決定一切, 事實上這在某些觀點就是: "條件".

說起來高有效性的層級是相當高的, 在某方面不是一個不夠資深的工程師能夠掌握的, 甚至可以說因為這是須要很高的經驗與知識, 沒有達到這些經驗時, 很難去做到, 加上這些又會受到公司架構的影響, 最後往往是決定在 IT Director, 但這個 Director 是否有這經驗去判斷, 須要依賴的就是相關經驗的顧問了.


上一篇
高有效性簡介30篇: 備份與復原 (12)
下一篇
高有效性簡介30篇: 災難管理 Disaster Management (14)
系列文
高有效性 (High Availability) 初論 30 講30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

0
食夢黑貘
iT邦研究生 3 級 ‧ 2011-10-23 23:01:07


理論上高效能運算與效能調校是我的專長, 說不定我明年鐵人賽就會寫這題目, 但也因為有太多可以寫, 反而夠難寫阿.

鐵殼心 iT邦高手 1 級 ‧ 2011-10-23 23:08:29 檢舉

期待中拍手

外獅佬 iT邦大師 1 級 ‧ 2011-10-23 23:10:18 檢舉

genehong提到:
太多可以寫, 反而夠難寫阿

可以做市調啊~~

我要留言

立即登入留言